1. PROPOSTES D’IDEES DEL PROJECTE
1.1. IDEA 1 (preferent): Biblioteca de Videojocs
1.1.1. Objectiu de l’app i quines necessitats resol
El nostre objectiu amb aquesta app, és fer un llistat de videojocs dividit entre les seves diferents categories (Acció, aventura, simulació, estratègia…), on els usuaris puguin afegir al seu perfil els jocs dividint-los en diferents apartats d’estat: Re-Jugat, Acabat, Jugant, Pendent o Rebutjat. I a més d’afegir-los al seu perfil, ho puguin afegir amb una qualificació del que els ha semblat el joc i afegir un comentari destinat a la comunitat.
Amb això el que volem aconseguir és, que els jugadors puguin tenir un seguiment dels videojocs que tenen pendents o acabats, que tinguin una opció eficaç per portar una organització i que a la vegada fomenti la socialització dels usuaris mitjançant un sistema que els permeti compartir les seves experiències i opinions amb la resta de jugadors.
1.1.2. Estudi de mercat
Al mercat d’aplicacions ja existeixen diverses opcions similars a la nostra app, però amb temàtiques diferents. Per exemple, MyAnimeList o AnimePlanet són aplicacions amb característiques similars, però centrades en anime i manga, així com GoodReads i TheStoryGraph on podem trobar el mateix concepte aplicat a llibres.
|
L’objectiu de la nostra aplicació és portar aquest concepte al món dels videojocs, ja que per a aquesta temàtica no existeix cap aplicació globalitzada de qualitat. A més en altres aplicacions amb aquest concepte es fomenta molt la socialització, i amb el cas dels videojocs això pot ser molt beneficiós perquè pot permetre no tan sols que les persones trobin més gent amb qui comparteixen gustos sinó que també podran trobar companys amb qui jugar unes partides als videojocs que ho permetin.
1.1.3. Target
La nostra aplicació està pensada per a un públic de totes les edats amb la motivació de compartir amb altres persones allò que gaudeixen, els videojocs. També pot estar orientada a persones que simplement volen portar un registre d’aquells videojocs que vol jugar o que ja ha jugat. Tot i que no hi ha gaires restriccions d’ús, l’aplicació només està disponible en tres idiomes, català, castellà i anglès i per usuaris d’Android.
1.1.4. Explicació dels termes "Categoria" i "Ítem"
En el cas de la nostra aplicació i entenent el terme “Categoria” com a un diferencial entre els ítems amb l’única finalitat de poder-los agrupar per a un filtratge previ o per a una fàcil navegació per l’aplicació. L’identifiquem com “els tipus de videojoc”, com ja hem esmentat, un videojoc pot ser d’aventures, d’acció, de simulació, etc.
En el cas d'"Item", per nosaltres és l’especificació d’un videojoc per exemple si la categoria és “Simulació”, trobaríem ítems com per exemple "Sims 4" o "Sims 3".
Per tal de deixar més clara la relació entre ambdós, cada videojoc (ítem), pot pertànyer a un tipus de videojoc (categoria), i les categories poden tenir cap, un o més videojocs.
1.1.5. Exemple de processos de negoci
En el cas de la nostra proposta d’aplicació, alguns exemples de processos de negoci que podem justificar des del principi, són els següents:
Primer de tot, qualsevol usuari pot afegir videojocs nous a la pàgina, això podria desencadenar en els usuaris creant jocs repetits, que vulnerin la legalitat o la llibertat d’altres persones, etc., per a combatre això hem decidit implementar un sistema on hi ha un administrador que valida els videojocs manualment.
La segona proposta de procés de negoci és que a l’hora de què un usuari vulgui afegir una puntuació/valoració al joc, haurà de primer haver afegit el joc a la seva biblioteca personal i haver-lo guardat com “Acabat”, així evitarem que qualsevol usuari que encara no hagi jugat ni acabar un videojoc pugui afegir una puntuació per a obtenir una mitjana de valoració més realista.
2. ESPECIFICACIÓ DE REQUISITS
2.1. Requisits no funcionals
Requisits Tècnics part frontend Mobile
-
(RN01) L’aplicació s’ha de desenvolupar utilitzant l’IDE Android Studio, implementant el llenguatge Kotlin per crear una aplicació nativa compatible amb dispositius Android.
-
(RN02) L’aplicació ha de tenir l’arquitectura MVVM (Model-View-ViewModel) i el ViewModel ha de gestionar l’estat de l’aplicació amb MutableStateFlow i StateFlow.
-
(RN03) S’ha d’utilitzar Jetpack Compose per implementar la interfície gràfica.
-
(RN07) S’ha d’utilitzar el git/gitlab per implementar el projecte en equip de forma òptima i adient.
-
(RN08) S’han de fer servir les següents branques: main/master, developer i branques per features, bugfix, etc.
-
(RN09) Tots els merges de funcionalitats s’han de fer per merge-request a developer.
-
(RN10) Les branques fusionades s’eliminen després del merge-request.
Requisits d’Interfície (UI/UX, Accessibilitat) frontend Mobile
-
(RN11) L’app ha d’estar en català, castellà i anglès.
-
(RN12) La interfície de l’usuari ha de complir amb les directrius de disseny Material Design. El disseny visual ha de ser atractiu amb coherència de colors, fonts, icones, bona distribució i agrupació de components. Mateix disseny per totes les pantalles.
-
(RN13) Responsive: En cas de variar la grandària de la pantalla del mòbil (no cal per tablet), s’ha d’adaptar el contingut de forma proporcionada.
-
(RN14) Usabilitat (UX): Interfície amigable, efectiva, intuïtiva i eficient. No pot haver-hi passos innecessaris entre el que vols fer i com fer-ho. Ha de quedar molt clar què es pot fer. També cal que tingui coherència amb les funcionalitats disponibles i no disponibles en cada moment.
-
(RN15) App accessible: Els elements interactius han de tenir etiquetes descriptives per facilitar-ne l’ús.
-
(RN16) S’ha d’utilitzar el menú Bottom Navigation per a la navegació a les funcionalitats principals.
Requisits operatius frontend Mobile
-
(RN17) L’app s’ha de poder executar en qualsevol emulador o dispositiu mòbil amb sistema operatiu Android.
-
(RN18) Fluïdesa: L’app ha de respondre a les entrades de l’usuari en tot moment. Això vol dir que en cap cas pot quedar “congelada” mentre realitza qualsevol operació.
-
(RN19) Gestió d’excepcions: Totes les possibles situacions excepcionals han de quedar gestionades de forma correcta i proporcionar missatges d’errors descriptius i útils per a l’usuari quan falli.
-
(RN20) El codi ha de ser optimitzat, eficient i sense redundàncies.
-
(RN21) S’han d’utilitzar les classes, interfícies i mètodes i packages de forma òptima i adient.
-
(RN22) Qualsevol entrada per teclat per part de l’usuari ha de validar-se i filtrar-se per garantir que les dades recollides siguin correctes, coherents i segures.
-
(RN23) Totes les capçaleres de mètodes i classes han d’estar degudament comentades en format JavaDOC en el frontend i backend.
-
(RN24) Els logs han d’estar disponibles per al monitoratge i depuració.
-
(RN25) L’aplicació ha de garantir que només els usuaris amb els permisos adequats puguin accedir a determinades funcionalitats.
-
(RN26) La capa presentació ha d’estar ubicada en el frontend Mobile.
-
(RN27) La comunicació entre el frontend Mobile i el backend s’ha de portar a terme mitjançant els principis REST.
-
(RN28) L’administrador pot fer totes les funcionalitats.
Requisits backend
-
(RN40) Les capes de servei, lógica de negoci i de persistència han d’estar ubicades al backend.
-
(RN42) El backend s’ha d’implementar mitjançant SpringBoot.
2.2. Requisits funcionals
-
(RF01) Login Usuari: L’usuari ha de poder iniciar sessió a l’aplicació amb el seu correu electrònic i contrasenya i sempre que estigui activat.
-
(RF02) Registre Usuari: L’usuari ha de poder registrar-se per poder utilitzar l’app. Un nou client enregistrat, per defecte està en estat desactivat.
-
(RF45) Registre d’administrador: Els administradors podran registrar nous administradors al sistema, afegint tota la informació necessària. (Afegida)
-
(RF03) Recuperar contrasenya: L’usuari ha de poder recuperar la contrasenya en cas d’oblit.
-
(RF04) Editar perfil usuari: L’usuari ha de poder modificar les dades del seu perfil, inclosa la seva foto.
-
(RF48) Consultar perfil d’usuari: Cada usuari podrà consultar el seu perfil d’usuari. (Afegida)
-
(RF05) Logout: L’usuari ha de poder tancar la sessió de manera segura.
-
(RF06) Validar Usuaris: L’administrador ha de poder canviar l’estat (activat o desactivat) dels usuaris enregistrats.
-
(RF07) Eliminar usuari: L’administrador ha de poder eliminar un usuari.
-
(RF08) Llistar usuaris: Tots els usuaris han de poder llistar tots els usuaris. (modificada)
-
(RF09) Modificar usuaris: L’administrador ha de poder modificar un usuari.
-
(RF44) Filtre d’usuaris: Tots els usuaris podran filtrar el llistat d’usuaris per nom d’usuari. (Afegida)
-
(RF46) Consultar usuaris: Tots els usuaris podran consultar/visualitzar el perfil de la resta d’usuaris, per veure la seva activitat de videojocs. (Afegida)
-
(RF10) Crear categoria: Crear un nou tipus. Només l’usuari administrador ha de poder crear un nou tipus de videojoc que contingui com a mínim un nom, una imatge i una descripció.
-
(RF11) Llistar categories: Llistar tipus de videojocs. L’usuari ha de poder veure una llista de tots els tipus existents.
-
(RF12) Filtrar per categoria: L’usuari ha de poder cercar tipus pel seu nom i veure els resultats ordenats alfabèticament.
-
(RF13) Consultar categoria: Ampliar informació dels tipus de videojocs. L’usuari ha de poder seleccionar un tipus de videojoc i veure tota la informació associada (nom, imatge i descripció).
-
(RF14) Modificar categoria: Modificar tipus de videojoc. Només l’usuari administrador ha de poder modificar el nom, la imatge i la descripció de qualsevol tipus.
-
(RF15) Eliminar categoria: Eliminar tipus de videojoc. Només l’usuari administrador ha de poder eliminar un tipus de videojoc, sempre que no tingui ítems associats.
-
(RF16) Filtrar Videojocs per Categories: L’usuari ha de poder veure només els videojocs que pertanyen a un tipus seleccionat.
-
(RF20) Afegir videojoc: L’usuari ha de poder crear un nou videojoc que contingui, com a mínim, una imatge, títol, descripció curta, data de creació, autor i categoria. El joc haurà de ser validat per un administrador.
-
(RF21) Llistar videojocs: L’usuari ha de poder veure una llista de tots els videojocs existents, mostrant-ne la imatge i títol, amb un botó per ampliar informació.
-
(RF22) Filtrar videojocs: L’usuari ha de poder filtrar els ítems basant-se en qualsevol dels camps disponibles dels ítems (com el títol, l’autor, o la data de creació, entre d’altres).
-
(RF23) Ordenar llistat de videojocs: Ordenar videojocs per camps. L’usuari ha de poder ordenar la llista dels videojocs segons qualsevol camp disponible, com el títol, la data de creació o l’autor.
-
(RF24) Consultar videojoc: Visualitzar la informació del videojoc. L’usuari ha de poder veure tots els detalls d’un videojoc seleccionat (títol, imatge, descripció, autor, data de creació).
-
(RF25) Modificar videojoc: L’administrador, ha de poder modificar-ne la informació d’un videojoc, excepte l’autor, la data de creació, les valoracions i els comentaris. (Modificada)
-
(RF26) Eliminar videojoc: L’administrador, han de poder eliminar un videojoc. (Modificada)
-
(RF40) Validar proposta de videojocs: L’administrador ha de validar les propostes de videojocs creades pels usuaris i acceptar o rebutjar-les. (Afegida)
-
*(RF41) Afegir videojoc a biblioteca personal: Tots els usuaris podran afegir jocs existents a la seva biblioteca personal, seleccionant l’estat en el qual es troba el joc (jugat, jugant, etc.). (Afegida)
-
(RF42) Modificar videojoc a la biblioteca personal: Tots els usuaris podran modificar l’estat dels jocs a la seva biblioteca personal. (Afegida)
-
(RF43) Eliminar videojoc de la biblioteca personal: Tots els usuaris podran eliminar un videojoc que de la seva biblioteca personal. (Afegida)
-
(RF47) Consultar biblioteca personal: Cada usuari podrà consultar la seva biblioteca personal. (Afegida)
-
(RF30) Afegir comentaris: Crear nou comentari d’un videojoc. L’usuari ha de poder crear un nou comentari que contingui, com a mínim una descripció curta, una puntuació, data de creació, autor.
-
(RF31) Llistar comentaris (per data de creació): Llistar comentaris d’un videojoc ordenats per data de creació. L’usuari ha de poder veure una llista de tots els comentaris existents d’un videojoc, mostrant-ne com a mínim la descripció, la puntuació, la data de creació i l’autor.
-
(RF32) Llistar comentaris (per puntuació): Llistar comentaris d’un videojoc ordenats per puntuació. L’usuari ha de poder veure una llista de tots els comentaris existents d’un videojoc, mostrant-ne com a mínim la descripció, la puntuació, la data de creació i l’autor.
-
(RF33) Visualitzar puntuació mitjana: Visualitzar puntuació mitjana dels comentaris d’un videojoc.
-
(RF34) Eliminar comentaris: Només l’administrador, han de poder eliminar.
3. GUIÓ D’ACTORS
3.1. Guió de client
| Actor | Client |
|---|---|
Descripció |
És l’usuari que accedeix al sistema per registrar-se, gestionar el seu perfil, i per cercar videojocs i categories. |
Guió |
(RF01) Login Usuari: L’usuari ha de poder iniciar sessió a l’aplicació amb el seu correu electrònic i contrasenya i sempre que estigui activat. |
3.2. Guió d’Administrador
| Actor | Administrador |
|---|---|
Descripció |
És l’usuari amb accés total al sistema per a afegir o eliminar informació, validar nova informació, i validar a usuaris. A més té accés a les funcionalitats “generals” de l’aplicació com qualsevol altre usuari. |
Guió |
(RF01) Login Usuari: L’usuari ha de poder iniciar sessió a l’aplicació amb el seu correu electrònic i contrasenya i sempre que estigui activat. |
5. Especificacions de casos d’ús de negoci
Validar proposta de videojocs
Nom: Validar proposta de videojocs
Descripció: L’administrador valida les propostes de videojocs que generen els usuaris. Podrà acceptar-les o rebutjar-les.
Actors: Administrador
Precondició: Iniciar sessió com a administrador.
| Flux Normal | Flux Alternatiu |
|---|---|
1. L’administrador inicia sessió amb les seves credencials |
|
2. L’administrador accedeix a la pantalla de videojocs |
|
3. Prem el botó de “validar usuaris” |
|
4. Es mostra una llista de tots els usuaris que necessiten validació. A cada entrada es troba un botó de visualitzar. |
4.1. Si no hi ha cap usuari pendent de validació, la llista apareixerà buida. |
5. Es mostrarà a detall la informació de l’usuari visualitzat amb un botó per validar i un per a rebutjar. |
Postcondició: L’usuari queda validat i pot accedir amb les seves credencials al sistema.